feat(sfs): make resource pool wait timeouts configurable - #1740

Description

relates to #1737

stackit_sfs_resource_pool cannot create a pool that STACKIT needs more than 10 minutes to
provision. CreateResourcePoolWaitHandler and its update/delete counterparts set
SetTimeout(10 * time.Minute), and the resource passed a context without a deadline, so that
default was the only limit and no configuration could reach it.

This adds a timeouts attribute (create/read/update/delete) following the pattern of
dremio/instance.

Why a context deadline and not SetTimeout

core/wait.WaitWithContext applies the handler's own timeout only when the incoming context
carries no deadline:

if _, ok := ctx.Deadline(); !ok {
	ctx, cancel = context.WithTimeout(ctx, h.timeout)
	defer cancel()
}

(core v0.26.0, wait.go)

Setting a context deadline per CRUD method therefore replaces the hardcoded value, and no
SetTimeout call is needed. Defaults stay at the wait handler value plus
core.DefaultTimeoutMargin, so unconfigured resources keep their current behaviour.
TestSfsResourcePoolCreateTimeout checks that a configured timeouts.create bounds the create.

The wait error

When a wait ends because this context's deadline expired, the error names the configured timeout and
suggests raising it. The wait handler reports terminal error states and failing polls through the
same error, so the hint is added only on the deadline path, and identically in create, update and
delete. The hint is utils.TimeoutHint in stackit/internal/utils, so other resources can reuse it;
TestTimeoutHint pins its text.

On point 2 of the issue

The issue also asks to keep the resource in state when the wait times out. That is already
implemented: utils.SetAndLogStateFields writes the IDs before the wait (CONTRIBUTING.md states
this as project doctrine, and TestSfsResourcePoolSavesIDsOnError covers it), the framework
initialises the create response state to a null object so no unknowns leak, and Terraform keeps the
object and marks it tainted rather than discarding it. What follows is a replace, not a lost entry.
No provider change was needed for that, only the corrected wording of the error.

testdata/resource-pool-max.tf sets timeouts, and no ImportStateVerifyIgnore is needed for it: terraform-plugin-testing deletes timeouts and timeouts.* from
both sides of the comparison unconditionally, after the ignore loop
(testing_new_import_state.go:398-411, v1.16.0).
The DNS acceptance tests rely on the same behaviour.

Not changed

sfs/share has the same hardcoded 10 minutes in all three of its wait handlers. Out of scope for
this issue — happy to follow up if wanted.

Checklist

• Issue was linked above
• Code format was applied: make fmt
• Examples were added / adjusted (see examples/ directory) — deliberately not: no example in examples/ has ever carried a timeouts block (git log -S timeouts -- examples/ is empty), and feat(dns) add timeouts to dns resources and datasources #1345, which added timeouts to the DNS resources, put the demonstrable configuration in testdata/resource-max.tf instead. Hardcoding durations on a registry page would also pin numbers that go stale when the SDK waiter default moves.
• Docs are up-to-date: make generate-docs (will be checked by CI)
• Unit tests got implemented or updated
• Acceptance tests got implemented or updated — testdata/resource-pool-max.tf now sets timeouts, mirroring dns/testdata/resource-max.tf, so TestAccResourcePoolResourceMax covers the attribute across create, import-verify and update
• Unit tests are passing: make test (will be checked by CI)
• No linter issues: make lint (will be checked by CI)